home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 2 / AACD 2.iso / AACD / Magazine / GraphicsCards / Warp3D / Developer / Source / Engine / README
Text File  |  1998-12-17  |  6KB  |  102 lines

  1. Warp Engine V1.0 Readme
  2. -----------------------
  3.  
  4. This engine is a tiny 3D engine in the style of games like System
  5. Shock. Essentially, a level is made up of 64x64 pixel grids, with
  6. arbitrary topology cells constructed from polygons that  are  not
  7. allowed to overlap the cell boundary. This allows for easy HSE by
  8. a breadth-first traversal of the map from  the  player  position.
  9. Clipping  is  done  in camera space before the actual projection.
  10. Each cell is convex, so that each cell may  be  rendered  in  any
  11. given order (a more complex cell layout would be easy to achieve,
  12. although this would require some kind of depth sorting  like  BSP
  13. trees).
  14.  
  15. Textures are "borrowed" from  the  source  code  distribution  of
  16. Alien  Breed  3  -  Killing Ground. I have converted some of them
  17. into PNG format, which the engine can load. The "data/" directory
  18. contains  the level and font, the former being a simple text file
  19. which is also commented, just in case you are mad enough  to  try
  20. and  modify  it  a  bit,  although this is tedious work without a
  21. level editor.
  22.  
  23. Source is also included. I intended to write a  game  with  this,
  24. but  I  now  have  something  better in mind (more in the line of
  25. Quake), so I release this source code as a kind  of  tutorial  on
  26. Warp3D  programming  (and  perhaps  also  as  a  tutorial  on  3D
  27. programming, although much of the stuff could be improved).  Much
  28. of this was inspired (in style and technique) by the two programs
  29. "Descent" and "QMap", the former being a first person shooter  by
  30. Parallax software (and ported to the Amiga by my brother and me),
  31. the second being a Quake Level viewer by  Sean  Barret,  which  I
  32. studied  while  investigating  3D  rendering  techniques  used by
  33. Quake. Although my code does not contain actual code from  those,
  34. it  was in places heavily inspired by them :-) If you want to use
  35. the code, go ahead, just don't sell it, and give  me  credit.  To
  36. compile,  you  will need SAS/C (StormC should also do, GNU C with
  37. minor modifications) and GNUMake. I only provide a GNU  makefile,
  38. SMake  is  far  too limited for my taste. To use the makefile you
  39. will  also  need  a  fairly  well  installed   ADE/Geek   Gadgets
  40. distribution, namely the fileutils and binutils.
  41.  
  42. In the demo, press the right mouse button and roll  your  rat  to
  43. move the view. The 's' and 'x' keys move forward/backwards, there
  44. are also some other keys mapped (play around a bit). No collusion
  45. detection  is  done  yet, so you can actually walk through walls.
  46. Also, the depth sorting is a bit broken, since I use a  recursive
  47. call,  and hence a stack, for traversal, which is of course utter
  48. bullshit, since it should use a queue. The  net  result  is  that
  49. there  might  be  overhanging  polygons  in certain places, but I
  50. won't fix that (try if you like). Hey, if you do a bigger  level,
  51. please  let me have it, too (although I doubt that anyone will do
  52. that!).
  53.  
  54. The FPS counter in the lower console will only update every  five
  55. or  so  seconds,  so  give it a few moments to come to live - the
  56. first FPS reading will  be  too  low,  because  the  startup  and
  57. loading  is  also  measured.  Also,  when  you  change one of the
  58. features (mapping, filtering), ignore the first  measure,  as  it
  59. will  also  be  unprecise. Moving the mouse pointer to the top of
  60. the screen reveals a menu. Click a  title  with  the  left  mouse
  61. button,  keep  it  pressed  and  release  it  over your choice to
  62. select. Finally, press ESC to quit.
  63.  
  64. Note that this is a very simple engine, yet it serves as a  small
  65. hint at what is possible with 3D hardware. The window at the cell
  66. in front of you is transparent, and the color can be  toggled  in
  67. the second menu. The red flashlight is dynamically implemented as
  68. gouraud shading, this comes almost for free on 3D  hardware  (the
  69. overhead  can  be  neglected).  On my machine, I get about 34 FPS
  70. with all features enabled, about 70 when everything  is  switched
  71. off.  This  is  on  a  Z2  machine,  an  Amiga 2000 with Blizzard
  72. 2060/50, and it shows what 3D Hardware can  do  for  a  Z2  based
  73. machine (of course, it's hard to beat such speeds on a Z3 machine
  74. too).
  75.  
  76. On the topic of speed, this demo might or might  not  run  a  bit
  77. slower  on  Picasso96.  This  is  mostly  due  to  the  fact that
  78. Picasso96 seems to sync the ScrollVPort to the Screen updates, so
  79. that  some  time  is  actually  "wasted" on waiting for the sync.
  80. While this gives a slight impact on performance,  it  also  makes
  81. the  thing look a bit cleaner. In fact, the ScrollVPort should no
  82. longer be used for Double buffering, alas, I've done it  in  this
  83. demo for a number of reasons:
  84.  
  85. -  Not  all  CyberGraphX  installations   can   really   do   V39
  86.    Multi-Buffering.
  87.  
  88. -  The Multi-Buffering code I've actually written is buggy, and I
  89.    just didn't have the time to look after it, and since it works
  90.    with the ScrollVPort, I didn't bother to look after it.
  91.    After all, we wanted to get Warp3D on the road.
  92.  
  93. I have included a screen mode requester, so that you can try  out
  94. different screen modes. I get around 34 FPS in 320x240, 13 FPS in
  95. 640x480 and around 1.9 FPS in 1024x768... If you have  a  320x400
  96. 15  bit  mode,  try  this, it's still quite usable. Note however,
  97. that the engine does not take the aspect ratio of the screen into
  98. account,  making the 320x400 mode look a bit streched. This would
  99. be easy to fix, I just didn't have the time. The whole engine was
  100. the work of about a week or so, but I knew pretty well what I was
  101. doing from the start.
  102.